Skip to content

Add browserless support#2825

Open
SnowyLeopard wants to merge 21 commits intonextcloud:masterfrom
SnowyLeopard:browserless_support
Open

Add browserless support#2825
SnowyLeopard wants to merge 21 commits intonextcloud:masterfrom
SnowyLeopard:browserless_support

Conversation

@SnowyLeopard
Copy link
Copy Markdown

Topic and Scope

Inspired by #2622 this adds support for the use of browserless(.io).
This allows fetching recipes from websites that need javascript to be executed and bypasses bot detection for some websites.

Concerns/issues

  • I haven't figured out yet how to store the token securely, now it is just saved as plain text in the DB.
  • Does this need more readme/how to documentation?

Formal requirements

There are some formal requirements that should be satisfied. Please mark those by checking the corresponding box.

  • I did check that the app can still be opened and does not throw any browser logs
  • I created tests for newly added PHP code (check this if no PHP changes were made)
  • I updated the OpenAPI specs and added an entry to the API changelog (check if API was not modified)
  • I notified the matrix channel if I introduced an API change

@provokateurin
Copy link
Copy Markdown
Member

I haven't figured out yet how to store the token securely, now it is just saved as plain text in the DB.

You can make appconfig values sensitive, then they are automatically stored in an encrypted form in the DB.

Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
Signed-off-by: SnowyLeopard <ricklucassen@gmail.com>
@SnowyLeopard SnowyLeopard force-pushed the browserless_support branch 2 times, most recently from ad8c01a to 87205c5 Compare March 18, 2026 13:13
Signed-off-by: SnowyLeopard <2438964+SnowyLeopard@users.noreply.github.com>
Signed-off-by: SnowyLeopard <2438964+SnowyLeopard@users.noreply.github.com>
@SnowyLeopard
Copy link
Copy Markdown
Author

@christianlupus Hi, I've updated this PR to make use of the IUserConfig, which allows for saving sensitive data.
Since the lowest supporting NC version is 31 I had to include it from the NCU, not sure if that is a big issue here.

Could you take a look and see if this would be something worth merging? Thanks!

@christianlupus
Copy link
Copy Markdown
Collaborator

Hello @SnowyLeopard!

First: Thanks for taking the time and working on this.

Generally speaking, I do not see anything standing against this. I see a few things that can and should be addressed, though.

  1. The tests only cover the PHP part. I have to admit that I feel a bit reluctant, as we are not testing the actual communication with the browserless service. I am considering whether it makes sense to install browserless within the CI pipeline and test the actual execution in integration tests.
  2. The DCO must be satisfied but this can be delayed a bit until we are on the right track. You could fix that if you like.
  3. The changes in the changelog are in the wrong file. Version 0.1.2 and 0.1.3 are already published. So, we would have to create a new version 0.1.4.
  4. Regarding the experimental classes/interfaces (namespace NCP): Currently, it is deprecated and will be removed once NC32 is EOL. We can keep it that way and will have to migrate to OCP in the next major upgrade. This is no big problem.
  5. Currently, you are using the download service to call a separate method to get a different behavior. This kind of feels redundant. I think into the direction to have one class for each download method (curl, browserless. More to come?) with a common interface/abstract parent class that allows easy handling. Then, the config can be used to provide the appropriate class and use polymophism. Again, just an idea to make it a pluggable module.

I was looking into the options to self-host browserless yesterday evening. This could work. But as I am no user of bowserles, I have zero experience. Thus, I have to do my own research first. Thus, this is just a quick and more or less uneducated guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants